![[新機能プレビュー] Amazon Q in QuickSight Scenarios でアップロードした CSV ファイルに自然言語（英語）で質問し AI によるインサイトを得てみた](https://images.ctfassets.net/ct0aopd36mqt/3aqf4zA8eWdIL3CoGscPpm/224083826f6e4dd7b971c4967b706ad8/reinvent-2024-try-jp.jpg)
[新機能プレビュー] Amazon Q in QuickSight Scenarios でアップロードした CSV ファイルに自然言語（英語）で質問し AI によるインサイトを得てみた
2024.12.26コーヒーが好きな emi です。
re:Invent 2024、2 日目 2024/12/3（現地時間）に Keynote で発表された Amazon Q in QuickSight Scenarios を使ってみました。アップロードした CSV ファイルに自然言語（英語）で質問し AI によるインサイトを得るところまでやってみます。
AWS re:Invent 2024 - Keynote with Dr. Swami Sivasubramanian 01:26:57
ドキュメントは以下で、始め方や操作方法が記載されています。
最初に所感
記事が長くなってしまったので先に所感を述べます。
個人的な感想ですが、「データを読み込めるすごく高性能な AI チャットアプリ」 という印象を受けました。
「画像やテキストファイルを読み込ませて回答してくれる AI チャットアプリが進化して、データを読み込んでビジュアル付きで回答してくれるようになりました！」という感じです。
Q in QuickSight で登場した「トピック」では「データセットに対して一問一答」でしたが、Scenario だと読み込ませたデータと前回までのやり取り・コンテキストを理解した上で問答を往復できるようなイメージです。
「データはあるけど何したらいいか分からん」 みたいなシーンで次の一手を考えるのに役立ちそうです。
使用可能リージョン
シナリオのプレビューは 2024/12/26 時点で以下 2 リージョンでのみ利用可能です。
- 米国東部（バージニア北部）（us-east-1）
- 米国西部 (オレゴン) (us-west-2)
ちなみに Q in QuickSight の機能自体が 2024/12/25 時点でまだ東京リージョンにありません。
0. Preview Manager から Q in QuickSight Scenarios の有効化
ベータ版機能である Q in QuickSight Scenarios を使うには Preview Manager（プレビューマネージャー）から有効化の作業が必要なのですが、最初に有効化しようとした際 Preview Manager が出てこなくて「？」となりました。
原因は、ログインしているユーザーがプロ権限ではなかったからです。別途プロ権限のユーザーを作成し、ログインし直すと、
ちゃんと Preview Manager が出てきました。
展開すると、注意書きがあります。
Preview Manager 有効化の注意書き
Preview Manager
Scenarios enable business users to automate data tasks and answer complex questions using simple natural language prompts. With the help of AI, users can overcome challenges with using spreadsheets to combine and manipulate data, and can dive deeper into their data than spreadsheets allow. As part of this new analysis experience, your data may be subject to cross-region inferencing within the United States. This means your data may be inferenced in us-east-1 or us-west-2 depending on relative load. Your data will not leave the United States. By using the new analysis experience you are acknowledging that your data is subject to this cross-region inferencing.
（機械翻訳）プレビューマネージャーAmazon QuickSightのシナリオにおけるQシナリオにより、ビジネスユーザーは簡単な自然言語の指示を使用して、データタスクを自動化したり、複雑な質問に回答したりすることができます。AIのサポートにより、ユーザーはスプレッドシートを使用してデータを結合および操作する際の課題を克服し、スプレッドシートでは不可能なレベルでデータを深く掘り下げて分析することができます。この新しい分析機能の一部として、お客様のデータは米国国内で地域間推論の対象となる場合があります。つまり、相対的な負荷に応じて、お客様のデータはus-east-1またはus-west-2で推論される可能性があります。お客様のデータは米国から送信されることはありません。新しい分析機能をご利用いただくことで、お客様のデータがこのクロスリージョン推論の対象となることに同意したものとみなされます。
内容を確認し、「保存」をクリックします。
Scenarios の項目が出るようになりました。「NEW SCENARIO」からシナリオを作成していきます。
ちなみに、この時点でデータセット、分析、ダッシュボード、トピック、データストーリーなどの別のアセットは何も作成していません。
1. シナリオの作成
「NEW SCENARIO」をクリックするとこんな画面になりました。
左上のメニューを見てみます。これは Outline（概要）で、シナリオの作成を進めると何か表示されるようです。
Data Source はまだ何もありません。
Add New Thread というボタンでスレッドというものを追加するようです。
さて、データが無いと何もできないので、Data Source メニューから読み込ませる元データを追加します。今回は
「UPLOAD FILE」をクリックしてファイルをアップロードすることにしました。
アップロードするファイルの注意
シナリオに追加されるデータには次の制限が適用されます。
- シナリオには最大 10 個のデータ ソースを追加できます。
- 各データ ソースには最大 100 万行を含めることができます。
- アップロードされるファイル形式は
.xlsxまたは.csvである必要があり、1 GB を超えることはできません。
ドキュメントには「ダッシュボードからは一度に最大 20 個のビジュアルを選択できます（Up to 20 visuals can be selected from a dashboard at a time.）。」と記載があるのですが、これは作成済みのダッシュボードからシナリオを作成する際の注意点のように読み取れます。私はダッシュボードからシナリオをまだ作成したことが無いので、あとで試してみます。
ということで、以下のブログで使った「部署ごとに保持しているお菓子の在庫」を記載した CSV ファイルをアップロードしました。
3KB 程度の小さな CSV でしたが、アップロード完了まで 1 分くらいかかってドキドキしました。アップロードしたファイルをクリックすると以下のように中身がプレビュー表示できます。右上の矢印を押すとプレビューが閉じます。
アップロードしたファイルの右の三点リーダをクリックすると「Rename」と「Remove」が選択できました。
ファイルの保存ボタンなどがあるのかな？と思ったのですが、特にないようです。
この後シナリオの作成をどう進めるか分からなくて「START ANALYSIS」ボタンを押したのですが、「Please enter a prompt to start your analysis.」という、エラーメッセージが出てしまいました。もうプロンプトを入れていいみたいです。
2. スレッドの開始
では「Number of rice crackers per section（課ごとのおせんべいの枚数）」と英語で入力して「START ANALYSIS」を押してみます。
「Start a Thread」と表示され、いくつか質問項目のようなものが出てきました。プロンプトを続けるためにこれらの提案から一つ選択する必要があるようです。
ちなみに画面下部の + - ボタンで画面の拡大縮小ができ、表示する場所を手マークのアイコンで掴んでぐいぐい変えられました。
ひとまず一番上の項目「Show the number of osenbei for each section」を選んでみます。選ぶと下部に表示され、「SUBMIT」ボタンが押せるようになりました。押します。
推論が始まります。20~30 秒くらい待ちました。
出ました。課ごとのおせんべいの枚数が表示されています。
このブロックの右上にいくつかボタンがあります。これはフラグボタンで、後で試すのですがここでフラグを押しておくと outline からフラグのブロックだけ表示するということができます。
三点リーダ（more）をクリックするとこんなメニューが出ます。「Copy Execution ID」を押下すると「e9182426-e6a0-4e43-8919-c2fa5edxxxxx」のような ID がコピーされました。
「Collapse」を見て「崩壊…？」となりましたが、「折りたたむ」という意味だそうです。
こんな感じで折りたたまれます。Expand で開きます。
さて、生成された結果はこんな感じです。
The sections with the highest osenbei counts are DocumentDB課 and EFS課, both with 84 osenbei, followed by RDS課 with 81 osenbei.
（機械翻訳）おせんべいの数が最も多いのはDocumentDB課とEFS課で、どちらも84個のおせんべい、次にRDS課が81個のおせんべいとなっています。
下部には表と、セクションごとのおせんべいの枚数が棒グラフで表示されました。
3. ブロック内の推論の修正
「Modify block」ボタンを押すとプロンプトを入力する画面が右に出ます。表示された推論結果が思い通りでなかった場合、ここから更にプロンプトを入力して編集できるようです。
「Create a visualization showing the daily trend of osenbei quantity over time.（おせんべいの数量の時系列的な日次傾向を示す可視化を作成する。）」と入力し、APPLY してみます。
おっと、私が 1 日分のデータしか CSV に含んでいなかったので、グラフがただの点になってしまいました。
The data shows only one day (2024-10-16) with 633 osenbei sold. This single data point is not sufficient to show a trend over time. You can try editing the block through popover to include a wider date range for a meaningful trend analysis.
（機械翻訳）データには、1日分（2024年10月16日）の販売数633個のみが示されています。この1つのデータだけでは、長期的な傾向を示すには不十分です。ポップオーバーでブロックを編集し、より長い期間を含めることで、有意義な傾向分析を行うことができます。
しっかり内容を理解してくれていますね。
もう一度「Modify block」ボタンからブロックを編集してみます。今度は「Show the hourly quantity of osenbei broken down by section.（おせんべいの時間ごとの数量をセクション別に分類して表示する）」と入力しました。
20 秒ほど経過。まだ推論しています。
40 秒ほど経過。まだ推論しています。
約 1 分ほどで結果が出ました。 やや待ちますね。さっきと比べて結構時間がかかりました。グラフとコメントが長く、リッチな結果です。
コメントを見ると、
Step 1
Step 1: Prepare the data by extracting the hour information from the timestamp.
A new column 'hour' has been added to the data, representing the hour of the day extracted from the 'datetime' column. This will allow us to analyze the hourly distribution of osenbei consumption across different sections.
（機械翻訳）ステップ1：タイムスタンプから時間情報を抽出してデータを準備します。データに「時間」という新しい列が追加され、「datetime」列から抽出されたその日の時間が表示されます。これにより、異なるセクションにおけるおせんべいの時間ごとの消費量を分析できるようになります。
Step 2
Step 2: Organize the data to show osenbei quantities for each hour and section.
The data has been summarized to show the total osenbei consumption for each section by hour. A stacked bar chart has been created to visualize this hourly breakdown across different sections.
（機械翻訳）ステップ 2: 各時間帯とセクションごとのせんべい消費量を表すようデータを整理する。データを要約して、各セクションの時間帯ごとのせんべい消費量の合計を表示します。積み上げ棒グラフを作成して、異なるセクションにおける時間帯別の内訳を視覚化します。
…というように、ステップごとに「今、推論で何をしているか」を順次出力してくれています。 待っている間にプロセスが見えるというわけですね。プロセスが見えれば、追加で「ここの考え方が違うのでこうしてほしい」みたいな追加指示もしやすいです。 これは Chain of Thought (CoT) 推論ということですかね。
I apologize, but I don't have enough information to provide a comprehensive summary of the osenbei consumption patterns throughout the day. The data shown only includes hours 17 and 18, which is not sufficient to identify trends across the entire day. To provide meaningful insights, we would need data for more hours, ideally covering a full 24-hour period.
（機械翻訳）申し訳ありませんが、1日の間のせんべい消費パターンの包括的な概要を提供できるだけの十分な情報はありません。表示されているデータは17時と18時のみであり、1日の間の傾向を特定するには不十分です。有意義な洞察を提供するには、より多くの時間帯のデータ、理想的には24時間分のデータが必要です。
Would you like me to request additional data for the remaining hours of the day? This would allow us to analyze the full daily pattern of osenbei consumption across different sections.
（機械翻訳）残りの時間帯のデータを追加でリクエストしましょうか？ そうすれば、異なるセクションにおけるおせんべいの消費の1日のパターン全体を分析することができます。
推論の結果から、他に必要な情報の要求と、追加でできることの提案までしてくれました。 新卒 1 年目の私より大分優秀です。
4. ブロックの追加（スレッドを続ける）
さて、ブロック下部の「+」マークを押すとスレッドを続けることができます。自分でプロンプトを入力することもできますし、提案されている項目から選ぶこともできます。
この中の「What factors are contributing to the higher osenbei consumption in the DocumentDB課 and EFS課 sections?（4. DocumentDB課とEFS課でおせんべい消費量が多くなっている要因は何か？）」というのが気になったので、クリックします。
適当に作ったデータなので、このデータからどんな仮説を導き出してくれるのか気になります。
ここからは 推論に 4 分ほどがかかりました。 途中経過はトグルにしまっています。
推論の途中経過
20 秒くらい。
40 秒くらい。
1 分 20 秒くらい。
2 分くらい。
4 分くらいで終わりました。
さて、推論の結果を見ていきます。
▼ステップ 1 では、DocumentDB 課と EFS 課が他部署と比べてどれくらいおせんべいの消費量が違うか数値を計算しています。
Step 1: We'll start by comparing how DocumentDB課 and EFS課 consume osenbei compared to other sections, looking at average consumption per hour.
DocumentDB課 and EFS課 have the highest average osenbei consumption at 28 per hour, which is 19.4% above the overall average of 23.4. Both sections show similar consumption patterns, with slightly higher consumption at 17:00 (29 osenbei) compared to 19:00 (27 osenbei).
（機械翻訳）ステップ 1: まず、DocumentDB課とEFS課のせんべい消費量を他の課と比較し、1時間当たりの平均消費量を見ていきます。DocumentDB課とEFS課は、1時間あたり28個のおせんべいを消費しており、これは全体の平均23.4個を19.4%上回っています。両部署とも、17:00（29個）が19:00（27個）よりも若干多いという、同様の消費パターンを示しています。
▼ステップ 2 では、部署と社員のステータスがおせんべいの消費に影響を与えているかを検証しています。
Step 2: We'll examine how the department and employee status might influence osenbei consumption, particularly in DocumentDB課 and EFS課 compared to other sections.
Still analyzing... Hang tight...
The データベース部 (Database Department) has the highest osenbei consumption, particularly when employees are in "不調" (not feeling well) or "普通" (normal) status. DocumentDB課, part of データベース部, consumes more osenbei (28) than its department average (26.95). EFS課, in ストレージ部 (Storage Department), also consumes more (28) than its department average (21.75) and status average (25.25 for "超ごきげん" or very good mood).
（機械翻訳）ステップ 2: 部署と社員のステータスが、特に DocumentDB課とEFS課において、おせんべいの消費にどのような影響を与えているかを検証します。まだ分析中... もう少しお待ちください...データベース部 (Database Department) は、社員が「不調」（体調不良）または「普通」のステータスの場合、おせんべいの消費量が最も多くなります。データベース部の一部門であるDocumentDB課では、部署平均（26.95）よりも多くのおせんべい（28）が消費されています。ストレージ部（Storage Department）のEFS課でも、部署平均（21.75）およびステータス平均（「超ごきげん」または非常に良い気分で25.25）よりも多くのおせんべい（28）が消費されています。
▼ヒートマップで、おせんべいの消費量と各部署のステータスを表現しています。ヒートマップの使い方がうまいです。
▼ステップ 3 では、おせんべい以外のお菓子の消費量との関係を調べています。
Step 3: We'll investigate if the higher osenbei consumption in DocumentDB課 and EFS課 is part of a general preference for sweets in these sections, by analyzing the consumption patterns of chocolate and donuts alongside osenbei.
Still analyzing... Hang tight...
Still analyzing... Hang tight...
DocumentDB課 and EFS課 have higher osenbei consumption (28 each) compared to other sections' average (22.1). However, their sweet consumption patterns differ: DocumentDB課 has a higher chocolate intake (18.3) and lower donut intake (6.7), while EFS課 has high donut consumption (22.0). Osenbei makes up 52.8% of total sweets for DocumentDB課 and 41.8% for EFS課, compared to 48.2% for other sections on average.
（機械翻訳）ステップ 3: おせんべいの消費量が多いDocumentDB課とEFS課では、他のセクションでもお菓子全般の消費量が多い傾向にあるのかどうかを、おせんべいとチョコレート、ドーナツの消費パターンを分析することで調査します。分析中... しばらくお待ちください...分析中... しばらくお待ちください...DocumentDB課とEFS課では、他のセクションの平均（22.1）と比較しておせんべいの消費量が多く（28）、 しかし、その甘い物の消費パターンは異なります。DocumentDB課はチョコレートの摂取量が多く（18.3）、ドーナツの摂取量は少ない（6.7）のに対し、EFS課はドーナツの摂取量が多く（22.0）です。おせんべいは、DocumentDB課では甘い物の総消費量の52.8%を占め、EFS課では41.8%を占めています。一方、他部署の平均では48.2%となっています。
▼散布図でバブルチャートを作成しています。ビジュアルの選択の仕方が勉強になります。
▼他のお菓子との Consumption（消費量）を比較する円グラフです。
▼ステップ 4 では、結果と考察を述べてくれます。
Step 4: We'll now summarize our findings and highlight the main factors that contribute to higher osenbei consumption in DocumentDB課 and EFS課, offering possible explanations for these patterns.
Based on our analysis, several factors contribute to the higher osenbei consumption in DocumentDB課 and EFS課:
（機械翻訳）ステップ 4: ここからは、DocumentDB課とEFS課におけるおせんべい消費量増加の主な要因をまとめ、これらのパターンに対する説明を提示します。分析の結果、DocumentDB課とEFS課におけるおせんべい消費量増加の要因として、以下のものが考えられます。
- Department influence: Both sections belong to departments with high osenbei consumption. DocumentDB課 is part of the データベース部 (Database Department), which has the highest average osenbei consumption, particularly when employees are in "不調" (not feeling well) or "普通" (normal) status. EFS課, part of the ストレージ部 (Storage Department), also shows above-average consumption.
（機械翻訳）部署の影響：両部署とも、おせんべい消費量が多い部署に属している。DocumentDB課は、データベース部（Database Department）に属しており、この部署は、特に「不調」（体調が優れない）や「普通」（通常）の状態にある社員の平均おせんべい消費量が最も多い。ストレージ部（Storage Department）に属するEFS課も、平均を上回る消費量を示している。
DocumentDB 課が所属するデータベース部は Status が「不調」～「普通」の場合におせんべいが多いことを事実として述べていますが、EFS 課は特に Status との関連は見つけられなかったようです。
- Section-specific trends: Both DocumentDB課 and EFS課 consume an average of 28 osenbei per hour, which is 19.4% above the overall average of 23.4. This suggests that these sections have unique factors driving higher osenbei consumption.
（機械翻訳）課別の傾向：DocumentDB課とEFS課は、1時間あたり平均28個のおせんべいを消費しており、これは全体の平均23.4個を19.4%上回っています。このことから、これらの課には、おせんべいの消費量を押し上げる独自の要因があることが分かります。
おせんべいの消費量が全体より 19.4% も上回っており、独自の要因がある可能性を述べています。
- Relationship with other sweets:
- DocumentDB課 shows a strong preference for osenbei and chocolate, with lower donut consumption. Osenbei makes up 52.8% of their total sweet intake.
- EFS課 has high consumption of both osenbei and donuts, with osenbei accounting for 41.8% of their total sweet intake.
（機械翻訳）他の菓子との関係：
- DocumentDB課は、おせんべいとチョコレートを強く好み、ドーナツの消費量は少ない。おせんべいは、同課の甘いものの摂取量の52.8%を占めている。
- EFS課は、おせんべいとドーナツの両方を多く消費しており、おせんべいは同課の甘いものの摂取量の41.8%を占めている。
他のお菓子の消費量について述べています。
- Time patterns: Both sections show slightly higher consumption at 17:00 (29 osenbei) compared to 19:00 (27 osenbei), indicating a potential end-of-workday snacking trend.
（機械翻訳）時間パターン：両セクションとも、17時のせんべい消費量（29枚）が19時のせんべい消費量（27枚）よりもわずかに多いことから、仕事終わりの間食の傾向があることが示唆されます。
おせんべいの消費時間帯について述べています。
- Status correlation: In the データベース部, osenbei consumption is highest when employees are in "不調" (not feeling well) or "普通" (normal) status, suggesting that osenbei might be used as a comfort food or energy booster during less optimal conditions.
（機械翻訳）ステータス相関：データベース部では、社員が「不調」（体調が優れない）または「普通」（通常）の状態にあるときに、おせんべいの消費量が最も多いことが分かりました。これは、おせんべいが、最適とは言えない状況下で、気分を落ち着かせたり、活力を高めたりするために使用されている可能性を示唆しています。
「1.」からの考察でしょうか。DocumentDB 課が所属するデータベース部は Status とおせんべいの消費に関連があり、気分を落ち着かせるためにおせんべいを消費しているであろうと仮説を立てています。
- Sweet balance: While both sections have high osenbei consumption, they differ in their overall sweet consumption patterns. This suggests that osenbei might serve different purposes in each section - possibly as a primary snack in DocumentDB課 and as part of a broader snacking habit in EFS課.
（機械翻訳）甘味のバランス：両セクションともおせんべいの消費量は多いが、甘味の消費パターンは異なる。これは、おせんべいがそれぞれのセクションで異なる目的で食べられている可能性を示唆している。DocumentDB課では主に間食として、EFS課ではより幅広い間食習慣の一部として食べられているのかもしれない。
他のスイーツの食べられ方とおせんべいの食べられ方の違いから、何か別の目的があるのかもしれないと仮説を立てています。
These patterns could be explained by factors such as:
- Work nature: Database and storage-related work might be more mentally demanding, leading to higher snack consumption for energy and focus.
- Team culture: These sections might have developed a culture of snacking on osenbei, possibly due to team preferences or habits.
- Stress levels: Higher osenbei consumption during "不調" status suggests it might be used as a stress-relief mechanism.
- Availability: There could be better access to osenbei in these sections, either through vending machines or regular office supplies.
To fully understand these trends, it would be beneficial to gather more qualitative data about team dynamics, work processes, and snacking habits in these sections.（機械翻訳）これらのパターンは、次のような要因によって説明できる。
- 仕事の性質：データベースやストレージ関連の仕事は、より精神的に厳しい可能性があり、エネルギーと集中力を得るために間食の消費量が増える。
- チーム文化：これらの部門では、チームの好みや習慣から、おせんべいを間食とする文化が発展したのかもしれない。
- ストレスレベル：「不調」状態ではおせんべいの消費量が増えることから、ストレス解消の手段として利用されている可能性がある。
- 入手可能性：これらのセクションでは、自動販売機や通常のオフィス用品を通じて、おせんべいをより入手しやすい環境にある可能性がある。
これらの傾向を十分に理解するためには、チームの力学、業務プロセス、これらのセクションにおける間食の習慣などに関する定性的なデータをさらに収集することが有益である。
なるほど… DocumentDB 課と EFS 課では仕事の性質やストレスレベルによっておせんべいの消費量が多いのかもしれないという仮説ですね…。確かに入手可能性も関係あるかもしれません。
次の考察やデータ収集を進めるために必要な仮説がいくつか立ちました。データから調査を進める際に役立ちそうです。
5. 別のスレッドを立てる
画面左上のメニューで「Outline（概要）」を見ると、これまで進めてきたスレッドから、このシナリオの概要が分かるようになっています。それぞれのブロックで何をプロンプトとして入力したか確認できます。
ここで「ADD」をクリックすると、今までのスレッドとは別に横に新しいスレッドを追加することができました。色々な可能性の枝を横に展開できるという感じですね。
ちなみに以下の「ADD」アイコンからも新しいスレッドを開始できました。
6. その他
各ブロックにはフラグを立てることができて、Outline の「Flagged only」チェックをオンにすると、フラグを立てたブロックのみ一覧を見ることができます。
スレッドエリアの画面左下にある「fit view」をクリックすると、スレッド全体が表示されます。全体像を見る際に良いです。
QuickSight アイコンから QuickSight トップに戻ると、New Scenario が追加されているのが分かります。特に保存ボタンなど押さなくても保存されるようです。右の三点リーダからは「View」と「Delete」が選択できました。
ちなみにここまで Scenario しか操作していませんが、データソース、データセット、分析、ダッシュボード、トピックなどの他のアセットは何もできていませんでした。Scenario のみでリソースは完結しています。
データソースができたりしていないかな？と思い「データセットの作成」からデータソースが無いか確認して見ましたが、何もありませんでした。
終わりに
繰り返しの感想ですが、「データを読み込めるすごく高性能な AI チャットアプリ」 という印象を受けました。
「画像やテキストファイルを読み込ませて回答してくれる AI チャットアプリが進化して、データを読み込んでビジュアル付きで回答してくれるようになりました！」という感じです。めっちゃすごい GhatGPT Web アプリだ、と言われたら「なるほどな」と思うかもしれません。
Q in QuickSight で登場した「トピック」では「データセットに対して一問一答」でしたが、Scenario だと読み込ませたデータと前回までのやり取り・コンテキストを理解した上で問答を往復できるようなイメージです。
Q in QuickSight の代表的な機能である「Build a Visual」は「QuickSight の使い方がある程度わかっている BI エンジニアが、生成 AI を使って楽してダッシュボードを作成できます」という感じの機能だったのですが、今回のように元となるデータファイルをアップロードしてシナリオを作成する場合はゼロからデータに関する考察を得たりビジュアルを生成してくれたり、更に生成された考察やビジュアルに対して追加の質問もできます、といった感じで一歩進化した使い方ができそうです。
「データはあるけど何したらいいか分からん」 みたいなシーンで次の一手を考えるのに役立ちそうです。
以下のブログでは、既に作成済みのダッシュボードをシナリオに読み込んで問答しています。作成済みのダッシュボードからインサイトを得るのは「Executive Summary（エグゼクティブサマリー）」の機能でもできましたが、これも一問一答形式だったので、プロンプトでやり取りしながらスレッドをつなげていけるという点ではシナリオの方が深く踏み込んだ洞察を得ることができそうです。
あとはそうですね、「生成されたビジュアルはダッシュボードや分析に使えないのか」とか「考察をまとめてデータストーリーやレポートに使えないのか」とか、そういうところが気になったのでまた試してみます。
参考
他のやってみたブログや re:Invent でのワークショップレポートもリリースされているので併せてご覧ください。
![[レポート] Q in QuickSight を使って生成 AI でダッシュボードをゼロから生成するワークショップ「Empower executives: Self-service dashboards with Generative BI」 #NTA404 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
